The present invention relates generally to multi-tenant databases, and more particularly to systems and methods for dynamically generating network communication contracts for use between a database server and multiple client systems.
Simple Object Access Protocol (SOAP) is an XML-based protocol that provides a means for a system to access servers, services and objects in a platform-independent manner. Using SOAP, a system can communicate with services provided on a remote system without regard to the remote system's location, operating system or platform. The standard model for SOAP-based Web services on the Internet requires a singular contract defined by the server, called a Web Services Definition Language (WSDL), to talk to its Web service. Any client that wants to communicate with the Web service must adhere to that contract, and is restricted to using only the pre-defined strongly-typed objects and methods defined within that contract. These objects are sent over the network from client to server to access the Web service, and are typically useful in requesting information about information provided by the service or in creating and altering the data on the service.
Current implementations of server-side SOAP-based Web services rely on the pre-defined static contracts to enable their implementation. Knowing, a priori, the full set of strongly-typed objects defined in the contract, the server implements unique programmatic objects to map distinctly to each of the individual objects defined in the contract. Upon receiving a SOAP request from the client, the server takes each SOAP-represented object in that request and translates it to a pre-determined programmatic object equivalent. In Java, this would be using Java reflection to populate an instance of a Java class; in .NET, this would be using .NET reflection (e.g., system.reflection package) to populate a C# class.
For implementation, each object in the contract maps distinctly to an individual object on the server. The translation of SOAP-object to server-side object is one-to-one. Because the contract is static, both the objects and the translation of those objects on the server side remains bounded.
This model works well for single-tenant architectures, when the server has a single datamodel for all data being stored in the system across all customers. Regardless of which customers are using the system, the contract is static across all customers and is therefore applicable to all customers. This model, however, would not work well for multi-tenant database systems where multiple datamodels might be stored. In such systems, a single server would be required for each datamodel; clearly an untenable and unscalable solution.
In multi-tenant database systems, such as the salesforce.com service, a multi-tenant architecture is used wherein customer organizations (i.e., tenants) share database resources in one logical database. The database tables themselves are typically shared; each entity in the data model typically contains an organization_id column that distinguishes rows for each tenant. All queries and data manipulation in the context of a tenant filter on this (indexed) organization_id column to ensure proper security and the appearance of virtual private databases. In the salesforce.com system, for example, this strategy is used to expose standard entities such as Account, Contact, Lead, and Opportunity entities to customers.
However, customers may wish to add their own custom data to the database system in addition to the standard entities and fields provided with the standard application. In the salesforce.com system, for example, in which a single server is hosting a unique datamodel for each of the various individual customers, each customer is able to customize the datamodel to his own business purposes. Customization allows customers to add or remove fields from each server object, or create entirely new objects altogether. In effect, the datamodel is dynamic based on which customer is using the service. As a result, no singular server contract can be used to securely define the strongly-typed objects for all of salesforce.com's customers.
Unlike existing SOAP Web service implementations, such a multi-tenant Web service cannot have a unique programmatic object for each contract-defined SOAP-object. Doing so would require the server to dynamically generate and maintain programmatic objects for each customized object in the customer's datamodel. This is not scaleable given the unbounded number of customers and the unbounded number of customizations they can make to their unique datamodel.
Accordingly, it is desirable to provide systems and methods that offer a flexible approach to generating communication contracts for multiple data models so as to overcome the above and other problems.